30-23 之 Patterns of Enterprise Application Architecture 小總結

13th鐵人賽

871 瀏覽

今天我們簡單來整理一下，這幾個星期從《 Patterns of Enterprise Application Architecture - Martin Fowler 》這本書中所學習到的東西，先簡單來張圖。

這張圖涵蓋了我們前幾天所討論的東西。

Presentation Layer

這個層級是專門用來處理畫面的地方，書中雖然以模式來說只要提到 MVC，但是因為我覺得現在應該還蠻多人也有聽過 MVP 與 MVVM 所以我也一起拿來說一下。

MVC : 最常聽到，也是有最多版本的模式，最傳統的 MVC 三者 Model、View、Controller 是會相互有交集的，而不是 ASP.NET MVC 那種 View → Controller → Model。
MVP : 為了解除 View 與 Model 的耦合，雙方溝通完全改由 Presenter 來處理，我個人覺得 ASP.NET MVC 比較像這個。
MVVM : 其中 VM ViewModel 實現了畫面與資料的雙向綁定，現在很多前端 framework 都是以這個概念來實現。

相關連結 :

Presentation layer 與 domain layer 之間我們有提到兩個東西 :

會有這兩個東西主要原因在於 :

畫面要的東西，不見得與 domain 層的形狀一樣

所以 remote facade 是一種設計模式，來讓『外部使用更簡單』，而 DTO 本質上就是一個傳送給外部的物件，他的形狀比較接近 Presentation 需要用到的。

這裡主要有三種模式 :

Transaction script : 基本就是一個業務，想辦法完成就對了。
Domain model : 建立不同的 domain，然後該由那個 domain 處理的部份就由他來，與上面 transaction script 相比，我覺得重點在於職則分明。
Table module : 以每個資料表為一個類別，然後裡面提到與之對應的操作。

上面的 domain model 與 table module 事實上會有一個問題，那就是要在那裡串業務流程，以 domain model 來看職則分明，但問題是一定要有個地方來串啊 ? 對這就是 service。

然後這裡我們還有提到幾個我覺得算是 domain layer 的支援工具 :

UnitOfWork : 處理 transaction 的地方。
Repository : 我們很多時後，會有很多因為業務上的需要，所需要的一些資料庫特殊的操作，例如 select 某些特別要用的欄位，這種為了業務而寫的 query 就是放在 repository。沒有他 dataSource 層的形狀，就會慢慢和 domain 混在一起。
LazyLoading : 有一些資料，只有在需要時才需要 load 出來，如果每一次使用 domain 都要 load 所有資料，那會有性能瓶頸的。

相關連結 :

這裡就是專門處理與資料庫相關的操作，而不代有業務邏輯。

TableDataGateway : 每個物件都以表為單位，來提供操作。
RowDataGateway : 每個物件以 row 為單位，來提供操作。
Active Record: 以 table 為單位，來提供包含『業務』相關的操作，我覺得很接近 repository 想解決的事情。
Data Mapper : 專門提供資料庫操作並且與 domain model 一起使用，而且他可以跨表，因為它主要回傳的東西以 domain model 為單位，而 domain model 沒有限定只能一張表。

相關連結 :